Add a payment_metadata map in blinded * path contexts#4584
Open
TheBlueMatt wants to merge 4 commits intolightningdevkit:mainfrom
Open
Add a payment_metadata map in blinded * path contexts#4584TheBlueMatt wants to merge 4 commits intolightningdevkit:mainfrom
payment_metadata map in blinded * path contexts#4584TheBlueMatt wants to merge 4 commits intolightningdevkit:mainfrom
Conversation
We almost certainly don't want to be moving `option` TLVs during serialization, and while we had logic elsewhere to work around this previously its nice not to have to in the future.
|
👋 Thanks for assigning @jkczyz as a reviewer! |
TheBlueMatt
force-pushed
the
2026-04-bolt12-custom-data
branch
2 times, most recently
from
7c4e653 to
ee6ba89
Compare
Collaborator
|
No issues found. All previously flagged issues from prior review passes have been verified as resolved:
Verification completed across all changed files covering:
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4584 +/- ##
=======================================
Coverage 87.15% 87.15%
=======================================
Files 161 161
Lines 109251 109338 +87
Branches 109251 109338 +87
=======================================
+ Hits 95215 95296 +81
+ Misses 11560 11559 -1
- Partials 2476 2483 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
TheBlueMatt
force-pushed
the
2026-04-bolt12-custom-data
branch
from
ee6ba89 to
792846c
Compare
Similar to how BOLT 11 payments can use a `payment_metadata` to provide arbitrary bytes in the invoice to be communicated back to them when receiving, its useful to be able to provide some bytes which are communicated back upon receiving a payment. Here we do so in the BOLT 12 blinded path contexts, offering a `BTreeMap<u64, Vec<u8>>` instead to enable more easily including multiple sets of data. Also note that a `Router` building a blinded path is allowed to modify the `payment_metadata` without breaking the payment. Tests by claude
TheBlueMatt
force-pushed
the
2026-04-bolt12-custom-data
branch
from
792846c to
98cff64
Compare
Similar to how BOLT 11 payments can use a `payment_metadata` to provide arbitrary bytes in the invoice to be communicated back to them when receiving, its useful to be able to provide some bytes which are communicated back upon receiving a payment. Here we do so in the BOLT 12 blinded message path contexts, offering a `BTreeMap<u64, Vec<u8>>` instead to enable more easily including multiple sets of data. We don't yet wire it up to the public `ChannelManager` API, but do allow selecting values for those using the manual `OffersMessageFlow`. Tests by claude
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
TheBlueMatt
force-pushed
the
2026-04-bolt12-custom-data
branch
from
98cff64 to
b8375a7
Compare
tnull
reviewed
May 5, 2026
Contributor
There was a problem hiding this comment.
Looks good, but it would be nice to provide a bit more ergonomic/self-descriptive types here. At the very least we should document what the semantics of the u64s are (or rather, that there are ~none and the user is free to set them).
Tagging @jkczyz as second reviewer on this.
| } | ||
| impl PaymentContext { | ||
| /// Returns the additional payment metadata stored alongside this payment context, if any. | ||
| pub fn payment_metadata(&self) -> Option<&BTreeMap<u64, Vec<u8>>> { |
Contributor
There was a problem hiding this comment.
The return type here needs docs, in particular what the u64 is representing.
| /// | ||
| /// [`RecipientOnionFields::payment_metadata`]: crate::ln::outbound_payment::RecipientOnionFields::payment_metadata | ||
| /// [`Bolt11Invoice::payment_metadata`]: lightning_invoice::Bolt11Invoice::payment_metadata | ||
| pub payment_metadata: Option<BTreeMap<u64, Vec<u8>>>, |
Contributor
There was a problem hiding this comment.
See above: what are we expecting users to set the u64 to?
Shouldn't we rather use a dedicated PaymentMetadata type for this, or even an Option<Box<dyn Writeable>> or similar?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We do so both in the blinded message and payment paths, supporting async payments when data is injected in the blinded payment paths (eg via the
Router). We don't expose building offers with metadata yet.